Complex database applications usually include large numbers of components, such as packages, functions, views, and tables that depend on each other. Update of a single component of the database application may affect performance of a number of other components that depend on the updated component. As illustrated in FIG. 1, some existing mechanisms identify components that depend on the updated component and invalidate all those dependent components causing recompilation. Not only does this operation take a long time, it also requires taking database systems offline, which is highly undesirable. For example, taking offline a database application that supports Amazon.com features even for a day, will not only affect revenues of Amazon.com corporation, but will also significantly affect customer satisfaction.
Invalidation of all the dependent components, however, may not be necessary, because the updated feature may not be utilized by some or all of the dependent components. Thus, the ability to identify components that depend on the updated feature rather than on the entire updated component will reduce recompilation time, which in turn will reduce the offline time. However, none of the existing mechanisms are able to provide such finer grain dependency tracking.
What is needed, therefore, is a solution that overcomes these and other shortcomings of the prior art.